[微前端实战]---022技术填补与崩溃预防

原文出处：https://blog.csdn.net/qq_35812380/article/details/126132350

架构基础知识—技术填补与崩溃预防

一. 技术填补与崩溃预防?

技术填补-问题1

开发过程中因为时间紧迫导致的实现不合理
举例:查找10000以内的质数.

循环, 判断质数,放到结果集中

循环方式.筛选法

function findPrime(number) {
    const result = []
    for (let i = 0; i < number; i++) {
        let m = 0;
        for (let j = 0; j < i; j++) {
            if (i%j===0) {
                m = 1
                break
            }

        }
        if(m === 0 ){
            result.push(i)
        }

    }
    return result
}

function prime(number){
    const result = new Array(number).fill(1)
    const let = result.length
    for(let i = 2;i<=number;i++){
        let m = 2;
        let middle = m * i
        while (middle < len) {
            result[middle] = 0
            m ++
            middle = m * i
        }
    }
    return result.map((item, index)=>{
        if (item && index > 1) {
            return index
        }
    }).filter(item => item)
}

test.js

const num = 100000
console.time('start');// 打印时间

console.log(findPrime(num));

console.timeEnd('start');

技术填补-问题2

暂时没有想到更好的实现方式而妥协的版本
刚开始使用if…else 实现

判断过多,体积过大,不好查找问题在哪

演变为:责任链模式

方式1

function judge(a) {
    if(a > 100){
        return 100
    }

    if(a > 50){
        return 50
    }

    if(a > 20){
        return 20
    }

    if(a > 10){
        return 10
    }
    return 0
}

方式2

理解为, 如果大于100 ,将交给下一个函数实现, 如果大于50, 将交给下一个函数实现,向下传递,直到返回0结束 …

优势:

方法2比方法1 实现方式更加明朗
方案2的每一个条件可以单独独立出来, 作为一个单独的判断条件使用, 方案1 只能当作整体使用,不灵活了

function is100(a) {
    if(a > 100){
        return 100
    }

    return is50(a)
}


function is50(a) {
    if(a > 50){
        return 50
    }

    return is20(a)
}

function is20(a) {
    if(a > 20){
        return 20
    }

    return is10(a)
}

function is10(a) {
    if(a > 10){
        return 10
    }

    return 0
}

技术填补-问题3

架构设计前期没有考虑到的细节
交互细节 -> props 传递参数(交互冗余,流程较长)

层级多后,层级变多, props,传参不利于参数传递,不利于逻辑定位

使用全局状态管理方式实现参数传递, 减少了props的传递流程, 并且清晰了所有参数内容,将从那里进行修改.

技术填补-问题4

不合理的交互设计,导致技术实现复杂
交互难度,与设计人员沟通

技术填补-问题5

旧功能文档缺失,无正确扩展,修改与兼容旧功能,导致上线后问题剧增.

所有设计都是面向功能开发,并没有预留扩展与接口, 这样在做新功能时候,需要兼容旧功能的功能, 为之前的旧功能提供兼容版本, 兼容版本与当前版本可能相背,并不能按照之前的架构设计,进行设计,而要兼容旧功能

通过阶段性重构,将旧功能变为新功能,让旧功能符合新的架构设计内容,之后在进行新功能开发时候,便没有架构设计的差异,按照当前的架构设计,来进行功能开发

技术填补-后果1

修复变重构
小的技术债务不做偿还,最后会演变成一场大规模的重构工作,导致产出不高.

技术填补-后果2

影响开发速度
旧功能可能会影响新功能开发
技术债务的存在会导致整体开发需要兼容的点过多, 影响开发效率,极大影响上线速度,导致整体项目迭代缓慢,失去核心竞争力.

技术填补-后果3

容易陷入维护旧功能---->开发新功能---->兼容旧功能---->维护旧功能---->开发新功能…这样的恶性循环
直到旧功能维护时间过长

技术填补—解决方案1

优秀的架构设计是基础.(怀念我的架构 😃 ),

非常优秀的架构设计,兼容旧功能的开发, 兼容之后新功能开发,并不因为架构设计时间很长,而导致拖慢开发速度

必须能够有效处理当前需求可预见的情况,对于未知的,可能出现的特殊情况, 很小的改动就能解决问题.

简练精简的内容, 预留接口,扩充接口,不改变之前架构设计

技术填补—解决方案2

根据当前业务,进行合理的项目拆分,尽量的代码解耦合

针对业务情况进行纠错,专注项目, 没有过多设计与没有注重到的情况

必须有日志模块,操作日志, 错误日志, 业务日志等等.

方便业务运行,与纠错, 业务查找问题

技术填补—解决方案3

良好的技术培训与传帮带能力.
技术能力妥协方案, 注意的点与开发
让每一位开发者能够从更深一层次理解自己所需要实现的功能.对业务的理解
从最开始的代码规范,到熟悉业务,最后再到编写文档.从根源上解决

技术填补—解决方案4

充分的技术方案可以避免一部分技术债务的产生
技术方案是充分理解需求之后所能产生的对需求理想的实现方式,必要性不言而喻.
不同工程师之前可以相互review
CodeReview是非常重要的,同事也是对自身的一个提高, 需要看下别人的代码是如何实现的.
学习别人优秀的点能否被自己借鉴, 如果有的化,可以运用到自己的开发过程中.

技术填补—解决方案5

提升对于修复技术债务重要性的认知
工程师如果能够预见一个债务可能导致的问题, 自然愿意花时间去处理.避免出现测试与一些问题

技术填补—解决方案6

善于发现和定期处理一些技术债务

处理技术债务, 学习很多收益

勇于发现系统中的技术债务,让自己为系统负责

二总结

等产品上线后,开发就没有那么紧急了, 这个时间大家就可以找个时间处理技术债务,一边建立感情,一边品味下原来的代码,这种感觉及其酸爽

[微前端实战]---022技术填补与崩溃预防 ​

架构基础知识—技术填补与崩溃预防 ​

一. 技术填补与崩溃预防? ​

二 总结 ​

[微前端实战]---022技术填补与崩溃预防

架构基础知识—技术填补与崩溃预防

一. 技术填补与崩溃预防?

二总结